Skip to content

[TT-16977] fix: trigger release workflow on PR labeled event#8089

Merged
buger merged 1 commit intorelease-5.12.1from
fix/pr-labeled-trigger-release-5.12.1
Apr 17, 2026
Merged

[TT-16977] fix: trigger release workflow on PR labeled event#8089
buger merged 1 commit intorelease-5.12.1from
fix/pr-labeled-trigger-release-5.12.1

Conversation

@buger
Copy link
Copy Markdown
Member

@buger buger commented Apr 17, 2026

Summary

  • Add labeled to pull_request trigger types so dep-guard re-evaluates when deps-reviewed label is added.

Test plan

  • Adding deps-reviewed label triggers a new release workflow run

🤖 Generated with Claude Code

@buger @claude
fix: trigger release workflow on PR labeled event
b1aa499 
Adding deps-reviewed label after dep-guard fails didn't trigger a
new run. Add 'labeled' type so the workflow re-runs when the label
is added.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@buger buger requested a review from a team as a code owner April 17, 2026 13:54
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Apr 17, 2026

🚨 Jira Linter Failed

Commit: b1aa499
Failed at: 2026-04-17 13:55:39 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details 
failed to validate branch and PR title rules: branch name 'fix/pr-labeled-trigger-release-5.12.1' must contain a valid Jira ticket ID (e.g., ABC-123)

Next Steps

  • Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
  • Verify your PR title matches the branch's Jira ticket ID
  • Check that the Jira ticket exists and is accessible

This comment will be automatically deleted once the linter passes.

@probelabs
Copy link
Copy Markdown
Contributor

probelabs Bot commented Apr 17, 2026 •
edited
Loading

This PR updates the .github/workflows/release.yml GitHub Actions workflow to trigger on the pull_request labeled event. The goal is to re-run the workflow, specifically the dep-guard job, when a label such as deps-reviewed is added to a pull request. This ensures dependency checks are re-evaluated automatically after manual review and labeling.

Files Changed Analysis

  • .github/workflows/release.yml: Modified to add labeled to the list of pull_request trigger types. This is a single-line configuration change.

Architecture & Impact Assessment

  • What this PR accomplishes: It enables the release workflow to be triggered by the addition of a label to a pull request.
  • Key technical changes introduced: The on.pull_request.types array in the workflow file was expanded to include labeled.
  • Affected system components: This change affects the CI/CD pipeline by altering the trigger conditions for the release workflow. It will cause the workflow to run more frequently (i.e., whenever any label is added to a PR), which may increase CI resource consumption.

Scope Discovery & Context Expansion

  • The impact of this change is confined to the repository's CI/CD process and does not affect the application's runtime behavior. It's a process improvement to ensure that status changes, signified by labels, correctly trigger validation workflows. The context provided by the author indicates this is specifically for the deps-reviewed label, which suggests a manual gate in the development process that can now be automated.
Metadata
  • Review Effort: 1 / 5
  • Primary Label: chore

Powered by Visor from Probelabs

Last updated: 2026-04-17T13:56:20.411Z | Triggered by: pr_opened | Commit: b1aa499

💡 TIP: You can chat with Visor using /visor ask <your question>

@probelabs
Copy link
Copy Markdown
Contributor

probelabs Bot commented Apr 17, 2026 •
edited
Loading

Security Issues (1)

Severity Location Issue
🟡 Warning .github/workflows/release.yml:19
The `pull_request` trigger with the `labeled` event can be insecure. If a privileged user can be tricked into adding a label to a malicious pull request from a fork, the workflow could run with elevated permissions and access to secrets. This could allow an attacker to exfiltrate secrets or execute malicious code in a trusted context.
💡 SuggestionTo mitigate this risk, use the `pull_request_target` event instead of `pull_request` for workflows that need to run on events like labeling. `pull_request_target` runs in the context of the base repository with access to secrets, but it checks out the base branch, not the potentially malicious head of the pull request. If you need to evaluate the PR's code, ensure you check out the PR's head commit in a secure way, for example by using `actions/checkout` with the `ref` set to `refs/pull/${{ github.event.pull_request.number }}/merge`. Additionally, add a condition to the job to only run when the specific, expected label (e.g., 'deps-reviewed') is added, to avoid running on any label change.

Architecture Issues (1)

Severity Location Issue
🟡 Warning .github/workflows/release.yml:19
The workflow is configured to trigger on any pull request `labeled` event. According to the pull request description, the intent is to run the workflow only when the `deps-reviewed` label is added. The current implementation will trigger the workflow for any label addition, leading to unnecessary CI runs and resource consumption.
💡 SuggestionTo align with the intended behavior, add a condition to the relevant job(s) in this workflow to check for the specific label when the event type is `labeled`. This will prevent the workflow from running for irrelevant label changes.

For example, you can add an if condition to your job(s):

jobs:
  your-job-name:
    if: github.event_name != &#39;pull_request&#39; || github.event.action != &#39;labeled&#39; || github.event.label.name == &#39;deps-reviewed&#39;
    runs-on: ubuntu-latest
    steps:
      ...

This condition ensures the job runs for all triggers other than a pull_request labeled event, and for labeled events, it only runs if the label name is deps-reviewed.

Security Issues (1)

Severity Location Issue
🟡 Warning .github/workflows/release.yml:19
The `pull_request` trigger with the `labeled` event can be insecure. If a privileged user can be tricked into adding a label to a malicious pull request from a fork, the workflow could run with elevated permissions and access to secrets. This could allow an attacker to exfiltrate secrets or execute malicious code in a trusted context.
💡 SuggestionTo mitigate this risk, use the `pull_request_target` event instead of `pull_request` for workflows that need to run on events like labeling. `pull_request_target` runs in the context of the base repository with access to secrets, but it checks out the base branch, not the potentially malicious head of the pull request. If you need to evaluate the PR's code, ensure you check out the PR's head commit in a secure way, for example by using `actions/checkout` with the `ref` set to `refs/pull/${{ github.event.pull_request.number }}/merge`. Additionally, add a condition to the job to only run when the specific, expected label (e.g., 'deps-reviewed') is added, to avoid running on any label change.
\n\n ### Architecture Issues (1)
Severity Location Issue
🟡 Warning .github/workflows/release.yml:19
The workflow is configured to trigger on any pull request `labeled` event. According to the pull request description, the intent is to run the workflow only when the `deps-reviewed` label is added. The current implementation will trigger the workflow for any label addition, leading to unnecessary CI runs and resource consumption.
💡 SuggestionTo align with the intended behavior, add a condition to the relevant job(s) in this workflow to check for the specific label when the event type is `labeled`. This will prevent the workflow from running for irrelevant label changes.

For example, you can add an if condition to your job(s):

jobs:
  your-job-name:
    if: github.event_name != &#39;pull_request&#39; || github.event.action != &#39;labeled&#39; || github.event.label.name == &#39;deps-reviewed&#39;
    runs-on: ubuntu-latest
    steps:
      ...

This condition ensures the job runs for all triggers other than a pull_request labeled event, and for labeled events, it only runs if the label name is deps-reviewed.
\n\n \n\n

Quality Issues (1)

Severity Location Issue
🟡 Warning .github/workflows/release.yml:19
The `pull_request` trigger with `types: [labeled]` will cause this workflow to run every time any label is added to a pull request. This can lead to unnecessary workflow executions, consuming resources. The workflow should ideally only run when the specific `deps-reviewed` label is added, as mentioned in the pull request description.
💡 SuggestionAdd a condition to the jobs within this workflow to ensure they only execute when the relevant label (`deps-reviewed`) is applied. For example, add an `if` condition to each job that needs to run on this event: `if: github.event.action != 'labeled' || github.event.label.name == 'deps-reviewed'`.

Powered by Visor from Probelabs

Last updated: 2026-04-17T13:56:11.937Z | Triggered by: pr_opened | Commit: b1aa499

💡 TIP: You can chat with Visor using /visor ask <your question>

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Apr 17, 2026

API Changes

no api changes detected

@buger buger merged commit 5f30d57 into release-5.12.1 Apr 17, 2026
18 of 20 checks passed
@buger buger deleted the fix/pr-labeled-trigger-release-5.12.1 branch April 17, 2026 14:05
@probelabs probelabs Bot changed the title fix: trigger release workflow on PR labeled event [TT-16977] fix: trigger release workflow on PR labeled event Apr 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@buger